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25 TECHNICAL FIELD 

The present invention relates generally to a computer system for tracking 
references to objects and, more particularly, to a system that encapsulates the complexities of 
tracking objects as they come up and go down. 
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BACKGROUND 

The tracking of objects in computer systems can involve very complex 
processes. The processes are complex because the number of objects may be in the 
thousands, the objects may be distributed across many different computer systems, and the 
objects may frequently change states. For example, a distributed system to control the 
various systems in a large building may include hundreds of computers. These computers 
may control the lighting systems, the heating systems, the elevators, and various electronic 
systems (e.g., a television and a laserdisc player). The distributed system may instantiate an 
object for each of the devices that can be controlled or that can receive input or output. For 



Jrjjio example, an object may be instantiated for each light that can be separately controlled, and 
an object may be instantiated for each light switch. The number of such devices in a large 
building can be very large. 



m 



*^jV^A^* ^ Sfirh Inrgf riifitrHitH Fycfr*™ c t n pn snn* tV l fl t thry ^^ fi me tion cv ct 

jil portions of the system fail or go off-line for maintenance: — FOTexample, when one object 

hi — 

j~Q 15 goes down because of a failure^fiuie^ct5inputer, the objects that reference that failed object 
should not also iSail^iiTaddition, when the failed object eventually comes up, the objects that 
referpiKJe^ that failed object should be able to continue to access the object. This tracking of 
bj rf^^^lLihry go flo wn . i ml um i i 1 4 1 i ,1 11 b e v er y c o mpW , For exam ple ^bH-sr- hnye 
distributed system, there may be no guarantee that messages r elating to jw hsn^arr^object 
comes up or goes do^3l-^ : ©-^ 3 ecervea^ in the order in which they are generated or event 
"at all. Thus, applications accessing the objects need to perform these complex 
processes lo ensiue l lia h rcf o roncoG ar o current: — Current object model yhowever, provide 
^e rv little support for tracking objects in such com plex syste m^. 



Current object models, such as Microsoft's Component Object Model 
25 ("COM"), facilitate the implementing of complex systems that may use hundreds or 
thousands of objects. COM is more fully described in "Inside COM" by Dale Rogerson and 
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published by Microsoft Press in 1997. COM specifies that each object is to implement a 
certain interface referred to as the IUknown interface. An interface is a collection of 
functions that all are generally semantically related. The IUnknown interface provides a 
query interface function, an add reference function, and a release function. The query 
interface function is passed the identifier of an interface and returns a reference to that 
interface. The add reference and the release functions are used for reference counting the 
object. Each object that conforms to COM implements the IUknown interface. 

A client that requests to instantiate a COM object may receive a pointer to the 
IUknown interface in return. The client may then invoke the query interface function passing 
the identifier of another interface supported by that COM object. The query interface 
function returns a pointer to the requested interface. The client can then use the pointer to 
invoke one of the functions of the requested interface. Each interface of a COM object 
inherits the IUknown interface. Thus, each of these interfaces provide access to other 
interfaces and provides reference counting. Whenever a client duplicates a pointer to an 
interface of a COM object, the client is expected to invoke the add reference function, which 
increments the reference count to that COM object. Whenever the client no longer needs a 
pointer to an interface of a COM object, the client is expected to invoke the release function, 
which decrements the reference count to that COM object and destructs the COM object 
when the reference count goes to 0. 

SUMMARY 

A method and system for tracking the state of an entity (e.g., an object) on 
behalf of a client (e.g., an application program) is provided. The states of an entity include 
up and down. The tracking system of the present invention receives a request from a client 
to track the state of an entity. The hacking system then watches the state of the entity to 
detect when the entity enters the up state. When the entity enters the up state, the tracking 
system performs a behavior (e.g., notification) that is specified by the client to be performed 
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when the entity enters the up state. When the entity is in the up state, the tracking system 
monitors the state of the entity to detect when the entity enters the down state. When the 
entity enters the down state, the tracking system performs a behavior (e.g., notification) that 
is specified by the client to be performed when the entity enters the down state. When the 
5 tracking system receives a request from the client for a reference to the entity, the tracking 
system determines the current state of the entity and either provides a reference to the entity 
or indicates that a reference is not being provided. Such a reference allows a client to access 
the behavior of the entity. For example, the reference may be a pointer and the behavior is 
accessed by invoking a function of the entity using the pointer. 

CI 

Wio In one embodiment, the tracking system receives notifications when the state of 

W 

HU the entity has changed. When a notification is received, the tracking system retrieves a 
JpJ pointer to the entity. If the tracking system had previously retrieved a pointer to the entity, 
ly the tracking system determines whether the previously retrieved pointer and the newly 

O retrieved pointer point to the same occurrence (e.g., instantiation) of the entity. If the 

y i 

m 15 references do not point to the same occurrence, then the tracking system notifies the client 

in 

t Q that the entity has gone down and then notifies the client that the entity has come up. In this 
~ way, the client is made aware that the previously retrieved pointer is out-of-date and that a 
newly retrieved pointer is available. In one embodiment, the tracking system determines 
whether the pointers point to the same occurrence based on the time at which the occurrences 
20 were created. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a state diagram that shows the state of the object tracking system 
while it tracks an object. 

Figure 2 is a block diagram illustrating the components of a system that uses 
25 the object tracking system. 
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Figure 2A is a block diagram illustrating the communications between a client 
and a resource manager. 

Figure 2B is a block diagram illustrating the watching of a resource. 

Figure 2C is a block diagram illustrating the monitoring of a resource. 

Figure 3 is a block diagram illustrating data structures of the resource tracking 

system. 

Figure 4 is a block diagram illustrating components of the resource manager. 
Figures 5-7 illustrate the data structures of the objects of the resource tracking 

system. 

Figure 8 is a flow diagram of an example implementation of the resource 
monitor component of the resource manager. 

Figure 9 is a flow diagram of an example implementation of the 
processResIsUp function of the resource monitor component. 

Figure 10 is a flow diagram of an example use of a resource pointer by a client. 

Figure 11 is a flow diagram of an example implementation of the 
RegisterResource function. 

Figure 12 is a flow diagram of example implementation of the getResourcePtr 

function. 
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Figure 13 is a flow diagram of an example implementation of a 
UnregisterResource function. 



Figure 14 is a flow diagram of an example implementation of the 
Directory: :addNewResClient function. 

Figure 15 is a flow diagram of the example implementation of the 
Directory: :resIsUp function. 

Figure 16 is a flow diagram of an example implementation of the 
Directory: :busIsUp function. 

Figure 17 is a flow diagram of an example implementation of the 
Directory: :findRefRes function. 

Figure 18 is a flow diagram of an example implementation of the 
Directory:: going Away function. 

Figure 19 is a flow diagram of an example implementation of the watchRes 

function. 

Figure 20 is a flow diagram of an example implementation of the 
ResRef::sendEventAndProcess function. 

Figure 21 is a flow diagram of an example implementation of the 
ResRef : :processEventsAndFreeLock function. 

Figure 22 is a flow diagram of an example implementation of the ResRef: :Init 

function. 
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Figure 23 is a flow diagram of an example implementation of the 
ResRef : :processResIsUpMsg function. 



Figure 24 is a flow diagram of an example implementation of the 
ResRef : :processResIsDownMsg function. 

Figure 25 is a flow diagram of an example implementation of the 
ResRef: :processingClients function. 

Figure 26 is a flow diagram of an example implementation of the ResRef: :up 

function. 

Figure 27 is a flow diagram of an example implementation of the ResRef: :add 

function. 

Figure 28 is a flow diagram of an example implementation of the 
ResRef: :goingA way function. 

Figure 29 is a flow diagram of an example implementation of the 
ResRef: :getRefCountedPtr function. 

Figure 30 is a flow diagram of an example implementation of the 
ResRef: : delete Yourself function . 

Figure 31 is a flow diagram of an example implementation of the 
Client: :resIsUp function. 

Figure 32 is a flow diagram of an example implementation of the 
Client: :res!sDown function. 
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Figure 33 is a flow diagram of an example implementation of the 
Client: :delete Yourself function. 



Figure 34 is a flow diagram of example implementation of the 
Client: :resourceIsUp function. 

Figure 35 is a flow diagram of an example implementation of the ResourceUp 
function of the resource manager. 

Figure 36 is a flow diagram of an example implementation of the 
ResourceDown function of the resource manager. 

Figure 37 is a flow diagram of an example implementation of the 
Directory: :watchRes function. 

Figure 38 is a flow diagram of an example implementation of the 
Directory: :stopWatchingRes function. 

Figure 38A is a flow diagram of an example implementation of a 
watchResIsUp function of the resource manager. 

Figure 39 is a flow diagram of an example implementation of the 
ClientProcessIsDown function of the resource manager. 

Figure 40 is a flow diagram of an example implementation of the attach 
function of the bus manager. 

Figure 41 is a flow diagram of an example implementation of the detach 
function of the bus manager. 
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Figure 42 is a flow diagram of an example implementation of the watchRes 
function of the bus manager. 

Figure 43 is a flow diagram of an example implementation of the 
stopWatchingRes function of the bus manager. 

Figure 44 is a flow diagram of example implementation of the nodelsDown 
function of the bus manager. 

Figure 45 is a flow diagram of an example implementation of the 
Directory: :monitorRes function. 

Figure 46 is a flow diagram of example implementation of the 
Directory : :stopMonitoringRes function. 

Figure 46A is a flow diagram of an example implementation of a 
processServerlsDown function. 

Figure 47 is a flow diagram of an example implementation of a resIsDown 
function of the resource manager. 

Figure 48 is a flow diagram of an example implementation of a connectClient 
function of a server node. 

Figure 48A is a flow diagram of an example implementation of the monitor 
resource function of the server node. 

Figure 48B is a flow diagram of an example implementation of the stop 
monitoring resource function of the server node. 
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Figure 49 is a flow diagram of example implementation of the clientlsAlive 
function of a server node. 



Figure 50 is a flow diagram of an example implementation of the resIsDown 
function of a server node. 

Figure 51 is a flow diagram of an example implementation of a 
noKeepAliveReceived function of the server node. 

Figure 52 is a flow diagram of an example implementation of the 
processClientlsDown function of a server node. 

Figure 53 is a block diagram illustrating the communications between a server 
resource and a client resource when watching a property. 

Figure 54 is a block diagram of the components to support the watching of 
properties by a client resource. 

Figure 55 is a block diagram illustrating the components to support the 
watching of properties of a server resource. 

Figure 56 is a flow diagram of an example implementation of the watch 
property function of the server resource. 

Figure 57 is a flow diagram of an example implementation of the stop watching 
property function of the server resource. 

Figure 58 is a flow diagram of an example implementation of the monitor 
resource is down function of the server resource. 
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Figure 59 is a flow diagram of an example implementation of the set property 
function of the server resource. 

Figure 60 is a flow diagram of the process queue function. 

Figure 61 is a flow diagram of an example implementation of a register watch 
5 function of a client resource. 

Figure 62 is a flow diagram of an example implementation of the property set 

_ function of the client resource. 

D 

pi* Figure 63 is a block diagram illustrating components of the event system in one 

embodiment. 

ilrj 

iUio DETAILED DESCRIPTION 



A method and system for tracking the state of objects and references to the 
objects is provided. The object tracking system in one embodiment provides an 
asynchronous notification mechanism for notifying a client, when an object that is referenced 
by the client changes state in a distributed object environment. An object can be either in an 
15 up state (e.g., instantiated) or a down state (e.g., destructed). The object tracking system also 
provides a mechanism through which a client can register its interest in accessing an object, 
can retrieve a pointer to the object when the object is in the up state, and can unregister its 
interest in accessing the object. The object tracking system interacts with an object manager 
that provides the facility to locate objects, to monitor the state of objects, and to retrieve 
20 pointers to the objects. The object manager notifies the object tracking system when objects 
change state. The object tracking system hides the complexities of tracking object state 
changes from the clients by working in conjunction with an installable object manager. In 
one embodiment, the object tracking system allows multiple clients to register their interests 
in the same object. A client as used in this specification refers to a process, a thread of 
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execution within a process, a routine, a module, a program, or some other programming 
entity that may need to track changes in state of an object. 

Figure 1 is a state diagram that shows the state of the object tracking system 
while it tracks an object. The four states are wailing for a client to register an interest in the 
5 object 101, initializing a reference to the object 102, watching for the object to enter the up 
state 103, and monitoring the object to enter the down state 104. When the object tracking 
system is in the waiting for a client state and it receives a register client request 105, it enters 
the initializing object reference state. During the initializing object reference state, the object 
y tracking system creates the data structures necessary to track the object for the client and 

Wio determines the current state of the object. If the object is in the up state, then the object 

m 

ry tracking system notifies the client that the object is up 107 and enters the monitoring object 

jj state, else the object tracking system notifies the client that the object is down 106 and enters 

^ the watching object state. In the watching object state, the object tracking system waits until 

O it receives notification from the object manager that the object has entered the up state 108 

y i 

ifyis and when notification is received, it notifies the clients and provides a pointer to the object 
jg and enters the monitoring object state. If the object tracking system receives a register client 

an 

~ request 109 while in the watching object state, it allocates the data structures for tracking the 
object for that client, notifies the client that the object is down, and stays in the watching 
object state. If the object tracking system receives a request to unregister a client 1 10-111, it 
20 deallocates the data structures for tracking that object for the client. The object tracking 
system then enters the waiting for client state if no clients are left as registered. Otherwise, 
the object tracking system stays in the watching object state. In the monitoring object state, 
the object tracking system waits until it receives notification from the object manager that the 
object has entered the down state, and when so notified, it notifies the clients 112 and enters 
25 the watching object state. If the object tracking system receives a register client request 113 
while in the monitoring object state, it allocates the data structures for tracking the object for 
the client, notifies the client that the object is up, and stays in the monitoring object state. If 
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the object tracking system receives a request to unregister a client 114-115, it deallocates the 
data structures for tracking that object for the client. The object tracking system then enters 
the waiting for client state if no clients are left as registered. Otherwise, the object tracking 
system stays in the monitoring object state. The term "component" refers to any hardware or 
5 software entity that can be tracked. A hardware component may be a device such as a CD 
player, and a software component may be a computer routine, object, thread, process, and so 
on. A software component may serve to control a hardware component. For example, a 
software component may serve as a programmatic interface to a CD player. The objects and 
resources are types of software components; and the object tracking system can be used to 
5io track any software component. A "tracking reference" is a reference that identifies a 

^ software component and can be used to request that the availability of a software component 

lit? 

be tracked. A software component that requests that another software component be tracked 

1=0 

[Jf may be notified when the tracked software component becomes available (up) and 
p~ unavailable (down). When a software component becomes available a "behavioral 

1^15 reference" can be retrieved and used to access the behavior of the software component so 

y § 

£U long as the software component stays available. For example, a tracking reference may be 

yy 

vO the name of a software component, and a behavioral reference may be a pointer to a software 

d 

component. 

The object tracking system correctly tracks the state of objects in environments 
20 where the objects are long-lived and where there is no guarantee that notification of changes 
in the state of objects will be received in the same order as they are generated. For example, 
an object may correspond to and monitor a real-world component (e.g., a light). Since the 
real-world component is always in an up state in the sense that it can always be utilized, the 
corresponding object should always be in the up state. A client that also corresponds to a 
25 real-world component (e.g., a light switch) that wants to control the physical state of another 
real-world component (e.g., the light) may register an interest in the object that controls the 
other real-world component. While the client is executing, it may not need to actually access 
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the object for long periods of time. During that time period, the object may occasionally 
enter the down state because, for example, the computer on which the object resides has a 
failure or a new version of code for the object is provided. The object tracking system tracks 
these changes of states and notifies the client. When the client eventually decides to access 
the object, it requests the object tracking system to provide a pointer to the object. 

The object tracking system also tracks each new instantiation of an object to 
help ensure that current behavioral reference (e.g., pointer) held by the object tracking 
system points to the currently instantiated object. In one embodiment, the object tracking 
system uses the creation time of different instantiations of the same object to ensure the 
validity of a pointer. A problem may arise if the object tracking system receives notifications 
from the object manager that are out of order. For example, the object tracking system may 
receive two notifications that an object is up without receiving an intervening notification 
that the object is down. The two notifications that the object is up may correspond to either 
redundant notifications (e.g., because of retransmission) or notifications of two different 
instantiations of the object. Since the object tracking system may have a pointer to the 
object, it needs to ensure that the pointer is correct. In certain situations there is no guarantee 
that two pointers to the same instantiation of an object will be the same. In particular, the 
object may want to track the particular client to which a pointer is provided and may provide 
different valued pointers to track which client is accessing the object. For example, the 
object may want to track the clients to enforce different access rights for different clients. To 
ensure the pointer is current, the object backing system compares the creation time of the 
current object with the creation time of the object whose pointer it has. If the times are 
equal, then the object tracking system does not need to notify the clients that the object has 
changed state. If, however, the creation times are different, then the object tracking system 
can notify the clients and the clients can request new pointers as appropriate. 

Figure 2 is a block diagram illustrating the components of a system that uses 
the object tracking system. In the following, the terms "object* 1 and "resource" are used 
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interchangeably. These terms refer to any software entity that can be tracked and that may 
correspond to a real-world component. The system includes nodes 201 and a bus manager 
202 that are interconnected through a communications link or bus 204. The communications 
link can be any physical or logical means for communicating between entities. Each node 
may contain resources that request access to other resources. A resource that requests access 
to another resource is referred to as a client resource or client, and a resource that is accessed 
by another resource is referred to as a server resource or server. The bus manager tracks all 
the resources as they come up and go down. The bus manager receives notifications when 
each resource comes up and goes down. Each node on which a resource is located, referred 
to as a server node, notifies the bus manager when a resource comes up in that mode referred 
to as "attaching" and notifies the bus manager when a resource goes down in a process 
referred to as "detaching." 



U3 



33 ** m^rhmp nf «a rofnurrP ic ™nrrijnflt f fj by ti ll 1 ll ll '. I MMUMj^Pl , h\j \ ffrf* 



iode 



monitorin g nf a res o urce is p f rfprmpH nn n Hinnt tn^ i i/H i i uhIh Imik u/i i l i m 
from the bus manager. When a client wants tOJ^ateh-^esourc^ that it knows when the 
resource is in the up state, tlie-<iient node notifies the bus manager. The resource is 
identified using ajraeking reference. If the resource is already up, then the bus manager then 
notifies^the*client node that the resource is up. Otherwise, the bus manager notifies the client 
when the resource comes up. When the client node is notified that the resource is up, it 
fr us manager to s top watch ing for the lesouice. The muiiiloiing uf - a -fesqurce 
is performed on a peer-to-peer basis. That is, once a clienyioda^s-«fernTeaThat an resource 
has entered the up state^jTgstabfete directly with the server node that contains 

the j^stfurceT Once the connection is established, the client node notifies the server node 
eriodically that it is still up and running. If the server node does not receive this 

TRat the client node is no longu up and limning aild lesets its internal 

' *!c 



notification, it 

state accordin gly. Similarly, if the client node receives an error when sendingj ts 

n<jhfirfl f|rm tn the Qervef pn f ie, it assumes the S fi fver nnHe ic Hnmm nnH r(v*eK it c i n l pmal a -fite 
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.ac cordingly. Whon the -r esouice goes down, t he seivei node notifies t he clie n t nooe-ttamie 
resource is now down. Each node includes clients^DSrd^esomce^acking^^tem 206, and 
a resource manager lOT^^j&kfiTreqxxzsts the resource tracking system to provide pointers 
to resQiifees^iiHto notify the client when resources come up or go down. The resource 
racyog-systefn-nrteracts with the resource manager to watch, monitor, aiid^efeieidfe^gointers 
to the resource. The resource manager also detects whnTj^^mTyr" nn its node rmnmip nnrf 
go down and notify tiiejDjxs-^ftmrage^ nodes as appropriate. The nodes may all be 

coroputeT^ystems with a central processing unit, memory, and input/output devices. The 
lftw ar c compon ents and data simclmes uf these nodes may be stored on computer - readab le 
me4ium— such an memory, ijj-ku M, flexible disk, hard disk, and s o o n and ma y^e 
Jransmitted~via a daia transmission medium. 



Figure 2A is a block diagram illustrating the communications between a client 
and a resource manager. Client 2A01 sends various messages to the resource manager 2A02 
to request the watching and the monitoring of resources. The resource manager notifies the 
client by sending messages to the client that the resource has come up or gone down. In one 
embodiment, the message passing is generally performed by invoking functions of various 
objects that have the same name as the message. The client sends a watch resource message 
to request the resource manager to start watching for a resource to come up. The client sends 
a stop watching resource message to the resource manager to indicate that the client no 
longer wants or needs the resource manager to watch for a certain resource. The client sends 
a monitor resource message to request the resource manager to start monitoring for a 
resource that is up to go down. The resource manager detects (e.g., by receiving messages 
from the bus manager) when a resource that is being watched goes up and detects (e.g., by 
receiving an attach or detach message from the node on which the resource is located) when 
a resource that is being monitored goes down and sends a resource is up or a resource is 
down message to the client. The resource tracking system serves as an interface of the client 
to the resource manager. 
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Figure ? B is a block diagra m illustrating the watching'^rf-a-fesoufet 



it 



node 2B10 is a node on which a client 2B11 has requested tojvalch-fef-a^ resource to 
come up. The client node :tracks_jh£--*es0r^^ components 2B12 of the resource 
manage^ fhe resource manager includes a watched resource table 2B13, a process/resource 
list 2B14, and resource directory 2B15. The client and the resource manager interact as 
described in Figure 2A. The resource manager interacts with a bus manager 2B20 to notify 
J)usjnzui^ node go upanxTceme'-dow^ that the 

bus manager watch for a resource on the client node's behalf. The bus managertneludes a 
bus manager compo nent 2B21 that has a watched resource table ?B0 2--mTrta resource 
directpr5^2B23. The watched resource table at the client node contains an indication of each 
resource that a client located at that node has requested to watch along with an indication of 
th8 s i : equesfeftgxlignr^The resource directory at the client node contains die^3eiftifiQation of 
each resource that is currently up at the client node. The resource manager uses the resource 
dkectQi^to^e^notify theT5fi$-raaiiagerof the resources that are up in the event that the^tis 
ianager goes down and then comes back up^oT'When-afiother bus maBftger~taKescontrol of 
^bus. The resource manager similarly uses the watch ed rrawreertahle ro re-notffy.the bus 
manager of the resources that its clients are watching. The process/resource list identifies 
each resource by the process in which it is executing. When a process goes4#wn, the 

retiree manager cafTTT^4l ^ - prnreQg/reQn^ r ff^ \ \$ \ \q pnrify^J kg-4tn^^ that those 

resources are now down. The client nod e s ^pHs to thf» bus manager nn n tt nr h j£sgvjm>_ 
message whenever a resource comes up and a detach resou rce message whenever a resource 

gnpcHrvv^n_ T Ka^p44^TTf^n77Hp g errrl wafrh r<wwpi h niM CgflffP fTTfEp hue manager nO^fythe 
r mfr mflpag e i U n u l. nl w ,il i.li ing fnr a pm li r. ii lm ik i iiiu.h I n c.m ii ih up TI i h cl i en t nnrf e-Jreeps 

tfack ojl xhe-fese ttices tlial it s watching iit the- watched resource tabic. If a client ieiiuest s-4o 
watch a resou rce-th at ano t her client on the same node is already watching then the -rfient 
j\ ode doesji QL nee d t o q end another watch resource message to the bus manager. Thc - clicn t 

rmHg ^prid ^n ctnp uu^li hing tfx unirr ft m ^flgp tn thr Knc minngnr wI i hi i huh i i l uu^i n K In *l np 
watching fnr a re <;onrae -j£L come n p Th^ Himt n n d n nifty Wfl"t t n Vt^p w fltf*" n B for— ft — 
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rcsowee whenevei all of its client*; who wei'e watching llie resource request to stop wat 
the resource or whenever th£^reseurce~comes up" The client node sends a find resource 
message to the bus manager when it wants to retrieve a pointer to a resource. When a client 
wi es lip, the bus mnnng^r ^mfr ra wRtrhrd r^Aiirr^ ii up messngp lit r . n Ir TfienTftftdf that 
is watching that resource. The watched resource table of the bus manager_£ontatirs an 
identifier of each resource that is being watchedj^ a watch of 

that resource — ^teTesource directory of the bus manager contains an identifier of and a 



) pointer * n ftfl^h rp^mirpfi that is? rnirantly up - — Wlicn the - bus ma nager receives an^attach 
resource message, it updates the resource directoryjojnd^ is up. It then 



SlO 

m 

m 



cji§eicsniir"watched resource table to determine whether any client nodes are watching that 

isrmrcq Tf so, the bus manager sends a watched resource is 
node. When the bus manager receives a detach resource m essage , it updates its gescrarce 
dire£ter5Ttoindicate that the resource is now down. When the bus manager receives a node 
h . down message, it effectively detach e s all rcsomtts that w ere attac hed at die nude th ai is 

e. 



mi 

in 

1^15 now down and effe ctively fitnpn nll - thrnvH i rhrs I nmHi 

HI 



\ Figure 2C is a block diagram illustrating the monitoring of a resource. The 

* client node 2C10 includes a client resource 2C11 and a client-side monitor resource 
component 2C12, which is part of the resource manager. The server node 2C20 includes a 
server resource 2C21 and a server-side monitor resource component 2C22, which is part of 

20 the resource manager. The server-side monitor resource component and the client-side 
monitor resource component interact to effect the monitoring of resources on a peer-to-peer 
basis. Each node may be both a server node and a client node and thus may have both 
server-side and client-side monitor resource components. When a client wants to start 
monitoring a resource or to stop monitoring a resource, it sends a monitor resource or a stop 

25 monitoring resource message to the resource manager as described in Figure 2A. When the 
client node receives a request to monitor a resource from a client on that node, it uses the 
reference to the resource passed by the client to identify the server node at which the 
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resource is located. The client node then sends a connect client message to the server node if 
a connection is not already established. The connect client message includes a pointer to an 
interface of the client node along with a client context for the client node. When the server 
node receives the connect client request, it determines whether a connection has already been 
established with that client node. If a connection has already been established, then the 
server node assumes that the client node has gone down since the connection was last 
established and adjusts its state accordingly and returns an error to the client node. 
Otherwise, the server node returns a server context. If the client receives an error in return, it 
can again attempt to establish a connection with the server node. The combination of client 
context and server context uniquely identifies the connection. The client node periodically 
notifies the server node that the client node is still alive by sending a client is alive message. 
If the server node detects that a client is alive message has not been received from the client 
node during that period, then the server node assumes that the client node is down and 
cancels the connection with the client node. After a connection is established, the client 
node requests to monitor resources on a per resource basis. The client node sends a monitor 
resource message or a stop monitoring resource message to the server node identifying the 
resource. The server node records a mapping between the resource and the client node and 
notifies the client node when that resource goes down. If the resource is down when the 
monitor resource message is received, then the server node notifies the client node that the 
resource is down. The client node maintains a monitor resource table 2C13 and a client 
connection table 2C14. The monitor resource table contains a mapping of resources being 
monitored to the clients that requested to monitor the resources. The client connection table 
contains the identification of the server node to which the client nodes is connected along 
with the client context and the server context for the current connection. The server 
connection table 2C23 contains references to the client nodes to which the server node is 
connected along with the client context and the server context for the current connection. 
The monitoring node table 2C24 contains a mapping from each resource that is being 
monitored to the monitoring client nodes. 
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1. Resource Tracking System/Resource Manager Interface 

^^K ffi i re 1 is a M oc k di apram illustrating data structures of tho res o urce teaelaa g 
^^system. The resource tracking system provides a directory object 301^Jist^flJ^sottrcre 
reference objects 302, and^for^acb-^esimf^ reference object, a list of client objects 303. 
5 The directon^ebtSctprovides functions for controlling the access to resources by interacting 

Tth an jnQta11aVi1f> rfdnnma^mmn^pr I'hp Hirpr.mry nhjer.r tnahilairW M TP^nyrrp reference 



object for each resource that a client has registered to track. Each resource reference object 

v 



O 

y 
pj 

m 
m 

m 



mis 

m 



contains the name of the resrmrnp. find , if the rp<soiirr.p is up , .^iniqii ^rt^rtrffiT^^ of 

thej^soxifcr(erg., a pointer to the resource and the time at which the resource was created), 
^acrrresetir ce reference object also conlai ns- a - poin t ci to a client list - of - c li ent objec ts that 

eflohj-pj^ llm l h* < regkten i\ I n h,u,k l U^ c orresponding r esource. Whene^e r=a 

client^W gntS to ref erer^ \n a^fcAwy^ il ciljiplipc a rlient rthjprt rn thp rpgortri^tpu^ng 

^ystem^J^ 

th e client wh en the resour££_xhaHgcs its stale (t p .y., a call-back routine): — Sinc e, these data 

s ■ ' 1 r> 

structures may be acce ssed- xoncurr e nt l v hv multiple t h reads of execution, a ron ca Hrencv 

x naTia Efiniff nl ' tprhniqiin it im n< 1 ■ n r .m h| i ll ^ iln gtmntiira fi. — For PXanipK before 

acc essing a dal a-stmctnTes, a thread may 1rrclr-t he data ntruct u re and thpn nnl o r k i* -aftertRe 
.3£cess--i s complete : In thc4ullo vying, t he desciiption of the functions that - acc ess-4hese=data 
-sfrtrgtures omit these well-knbwtrcons urrency managementTechniqu^ 



20 Figure 4 is a block diagram illustrating components of the resource manager. 

The resource manager 400 includes a watch resource component 401a and monitor resource 
component 401b, an implementation of resource tracking functions of the directory object 
402-406, and a reference 407 to the directory object. The resource manager provides the 
implementation of the resource tracking functions so that the resource tracking system can be 

25 independent of the particular resource manager. For example, the resource manager may 
manage resources in the same computer in which the clients execute or on different 
computers that are connected via a local area network or connected via the Internet. Thus, 
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the resource manager is installable in the sense that the resource tracking system can interact 
with any resource manager that provides these functions and notifies the resource tracking 
system by invoking certain functions as specified below. The watch resource component and 
the monitor resource component each provide sub-components to support watching and 
5 monitoring of resources. 




Figures 5-7 illustrate the data structures of the objects of the resource tracking 
system. The tables on the left 501, 601, 701 contain the data of the objects and the tables on 
the right to 502, 602, 702 contain the names of the functions of the objects. Table 1 contains 
a description of the data and functions of each of these objects. 

- — »hecloiy Objeet 



(k 



- -SddNewKesetient- 



myResRefList 



resIsUp 



resIsDown 



busStateChanged 



reevaluateRefs 



goingAway 



monitorRes 



stop Monitor inftRes- 



watchRes 



slop Watch ip.flKe.s- 



4>e$al|Ui(iii" 



A pointer to the resource reference list for this directory object. 



■ A function that is inv oked by a client to register that it wants to track a resource. 
A function that is invoked by the resource manager to notify the teiioui 
system that a resource is up. 



c c -t racking — s 



A function that is invoked by the resource manager to notify the resource tracking 
system that a resource is down. 



A function that is invoked by the resource manager to notify the resource tracking 
system that the bus h as rhanfl A d s tate fl.g . , came up »r Hnwn^ 



A function that is invoked by the resource manager to notify the resour^rtracking 
system to r eset all its reference to the down state. 



Function that is invoked by the resource manager to notify the resource tracking 
system to start processing notifications. 



A function that is invoked by a resou 



object to notify the directory 



objeci that a resource reference object is going away. 



A function that is implemented by the resource manager and invoked by the 

tree ma nager to start monitoring a 
resource to go down. This function may be provided as a denvauurr-o£the directory- 
object. 



-A function tnai is implemented by the resource manager and invoked by the 
resource tracking system to notify the resource manager to stop monitoring a 
■ resource tu gu down, l his iunctiOri may be p r ovided as a derivation of the directbry 
object. = __^___ = ^__ 



A functio n that is implemented! by *h fi rpcniirrY»mnrwg 

re so urce tracking system tu notify the lusOurceTnanagej 

resource ^t o come up. This function may bc proviHed as a derivation of the directory 



gdbythe 
lo- start watchingTSt 



object. 



■ A function that is implemented by the res o urce r- managcr and inv oked by the 
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Name 



Disci iptiw- 



r^Sbl]iyCrtra6king syst em tn notify ihf * rnrnnrnn + m n> A£l*Y ftt l&mp wm fl lil lfl ftw U 

resource to comeup: — i f hi9 function may bo providod - as - a derivation offf fg^ 



directory opject. 



fmdRes 



-resotlite b a c king ayiitom to rctrirvr n point e r ton lesOlute. 1 ' lus lurifcUonlnayTfe 
piOVltled as- n dorivation - of the diroctory - objoct. ^ 



Resource Reference Object 



Name 


Description 


myClientList 


A pointer to the client list for this resource reference object. 


myResName 


The name of the resource. 


myResPtr 


A pointer to the resource. 


myResCreatedTime 


The time when the resource was created. 


myQueue 


A queue for notifications relating to this resource. 


mylsProcessing 


A flag indicating that a thread is processing the notifications that are on the 
queue. 


myDirPtr 


A pointer to the directory object. 


myResrcInstld 


A synonym for the name of the resource. 


getRefCountedPtr 


A function that returns a reference counted pointer to the resource. 


down 


A function that is invoked by the directory object to indicate that the 
resource has gone down. 


up 


A function that is invoked by the directory object to indicate that the 
resource has come up. 


add 


A function that adds a client object to the client list for this resource 
reference object. 


init 


A function invoked by the directory object to initialize the resource 
reference object. 


deleteYourself 


A function that is invoked by the directory object when it is destructed. 


goingAway 


A function that is called by a client object to notify the resource reference 
object that the client object is being deleted. 


clearClients 


A function that is invoked to remove the client objects from the client list. 


processEventsandFreeLock 


A function that processes the notifications that are on the queue. 


sendEventandProcess 


A function that adds notifications onto the queue. 


processResIsUpMsg 


A function that processes a notification that a resource is up. 


processResIsDownMsg 


A function that processes a notification that a resource is down. 


processResInitMsg 


A function that processes a notification to initialize this resource reference 
object. 


tellClientsResIsUp 


A function that is invoked to notify clients that a resource is up. 


tellClientsResIsDown 


A function that is invoked to notify clients that a resource is down. 


processClients 


A function that is invoked to invoke a passed function for each client object 
in the client list for this resource reference object. 


Client Object 



Name 


Description 


myRefResPtr 


A pointer to the resource reference object for this client object. 


mylID 


The interface identifier of the interface of the resource that the client wants 
returned. 


mylnterfacelsSet 


A flag that indicates whether the client wants a pointer maintained to a specific 
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Name 


Description 




interface of the resource. 


mylnterfacePtr 


The pointer to the interface. 


getRefCountedPtr 


A function that returns a reference counted pointer to the resource. 


getlnterfacePtr 


A function that returns a pointer to the interface. 


deleteYourseif 


A function that is invoked by the resource reference object when it is deleting 
itself. 


resIsUp 


A function that is invoked by the resource reference object to notify this client 
object that the resource is up. 


init 


A function that initializes the client object. 


resIsDown 


A function that is invoked by the resource reference object to notify this client 
object that the resource is down. 


resourcelsUp 


A function provided by the client that is invoked by this client object to notify the 
client that the resource is up. This function may be provided as a derivation of the 
client object. 


resourcelsDown 


A function provided by the client that is invoked by this client object to notify the 
client that the resource is down. This function may be provided as a derivation of 
the client object. 



A poiffltpr iiqpH mqy he "rmirt pointer" mrh tW when i pmnto y-k Copied 11 ~k 

a iit fti^afoal ly refere n ce counted. wh enr^ke-pomier is reset 10 a new it is automatically 
K&leq fteH When a s mart pointer goes P ^t nf scnpfi T-j^^-ttegfriictor releasET Ht The myRcsPtr 
-ftf- thp ret iree re ference object RflH myP cfT? nnPt i iiM i h Hien l Ohjw i r m^mgrt poin ters. 

Figure 8 is a flow diagram of an example implementation of the resource 
manager when it detects a change in state of a resource that is being watched or monitored by 
a client on this node. In step 801, if the resource manager detects that a resource has come 
up, then, in step 802, the resource manager invokes its processResIsUp function passing an 
identifier of the resource. In step 803, if the resource manager detects that the resource has 
gone down as indicated by the server node, then, in step 804, the resource manager invokes 
its processResIsDown function passing an identifier of the resource. In step 805, if the 
resource manager detects a change in the state of the bus, then, in step 806, the resource 
manager invokes its busStateChange function. 

Figure 9 is a flow diagram of an example implementation of the 
processResIsUp function of the resource manager. This function is passed an indication of 
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the resource and, if the resource is being tracked (i.e., watched or monitored), the function 
notifies the resource tracking system by invoking a function of the directory object. In steps 
901-903, the function loops selecting each resource that is being tracked to determine 
whether the notification is for that resource. In the step 901, the function selects the next 
5 tracked resource from a tracked list (e.g., the watched resource table), which contains the 
identification of the resources that are being tracked. In the step 902, if all the resources 
have already been selected, then the resource is not being tracked and the function returns, 
else the function continues at step 903. In step 903, if the selected resource matches the 
passed resource for which the notification was received, then the function continues at 
Jio step 904, else the function loops to step 901 to select the next resource. In step 904, the 
!jj function invokes the resIsUp function of the directory object passing the context of (e.g., 

£w pointer to the resource reference object for the resource) the resource, which was passed to 

y.y 

W\ the resource monitor as part of the registration process. The function then returns. The 

jry 

p~ resource manager implements an analogous function for processing resource down 

^15 notifications. The busStateChanged function causes each client to reset by invoking the 

p busStateChanged function of the directory object and resets it internal state. 

■ifbr 

lf\ 

te Figure 10 is a flow diagram of an example use of a resource pointer by a client. 

In step 1001, the client invokes to the RegisterResource function passing the name of the 
resource and receiving a handle to the resource in return. In step 1002, the function invokes 

20 the getResourcePtr function passing the handle to the resource and receiving a pointer to the 
resource in return. The client may periodically check whether it has been notified of a 
change in state in the resource. If so, the client can use the handle to retrieve a reference 
counted pointer to a current instantiation of the resource. When the client no longer needs 
the pointer, it releases the pointer. The client may also receive asynchronous notifications 

25 from the resource tracking system via the resourcelsUp and resourcelsDown functions that it 
implements and provides to the resource tracking system. 
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Figure 11 is a flow diagram of an example implementation of the 
RegisterResource function. This function is invoked by a client to register an interest in a 
resource. The client identifies the resource by providing the name of the resource. The 
function returns a handle that identifies the resource. The function has two parameters: the 
name of the resource instance (resInstName) and resource handle (resHandlePtr). In 
step 1101, the function creates a new element object, which is derived from a client object. 
The element object adds handle management to a client object. In the step 1 102, the function 
retrieves a handle for the new element object and sets the resource handle to be returned to 
the client to the retrieved value. In step 1103, the function adds the client object to the 
resource tracking system data structures by invoking the Directory: :addNewResClient 
function passing the resource name and the element object. The function returns after the 
client object has been added. The element object may maintain a mapping from the handles 
to the client objects in a handle resource table. Alternatively, the handle may be a pointer to 
the client object. 

Figure 12 is a flow diagram of example implementation of the getResourcePtr 
function. This function is passed the handle of a resource and returns a pointer to the 
resource. In step 1201, the function selects the next entry in the handle/resource table. In 
step 1202, if all the entries have already been selected, then the function returns an error, else 
the function continues at step 1203. In step 1203, if the passed handle matches the handle in 
the selected entry, then the function continues at step 1204, else the function loops to 
step 1201 to select the next entry. In step 1204, the function retrieves a reference counted 
pointer to the resource by invoking the getRefCountedPtr function of the client object that is 
indicated in the selected entry. The function then returns. 

Figure 13 is a flow diagram of an example implementation of a 
UnregisterResource function. This function undoes the processing of the RegisterResource 
function. This function is passed the handle for the resource. In step 1301, the function 
retrieves the client object by invoking the getClient function passing the handle. In 
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step 1302, the function directs the client object to delete itself by invoking the delete Yourself 
function of the client object. In step 1303, the function removes the handle from the 
handle/resource table and returns. 

A: Directory Object 




5 (/ /T^^ ^ ^Fig 11 ^ 14-1Q.asn flow H i ng r amg i llmfrnting the fnnrtinrK nf the director y 

"objects: Figure — H — rs — a flow — diagram of an example -i mplementation of the » 

^ Directory: :addNewResCliont function. Tliis function add s a new client obj 
to the directory. This function is passed thenaga£-ef-tfrfT : e^ (resName) and the client 
object. In step 1401^heJwtetiGirTi^ the resource reference object associated with the 
10 passedj^sotffcename by invoking the findRefRes function of the directory object. That 

e resource reterenceTTst and returns a reieTence^oaresource reference 
rwiih that name. In step 1402, it resource^refere nce object with dial name is found, 
t he function continues tha t step 1407 eke the function continues a t ste p 1403 Tn sfep s 
1403-1406, the function adds a resource reference object for the namedj^scan^te^ttie 



^thenJ 



ffi 



|ji5 tags gCTce referencej ist — In st e p H03, {heHmiction creaies^arreso ti r re r efere n c e, object. I n 



stepJ494rtfie lunction adds the resource lefeience ubjeel to t h e resouixe r e fe r ence list -of 
^tiu sjiirectory object. In step 1405, the function adds the cli e nt object to the client list of th e 

r esource reff r^^ nhjerf hy i n voking the add f action nf the resource rcfi i rmr nlijflh t 
jTflggjrjg the client object T T1 <^p 1406 the function frigrjflk tha-fito.iiK llui llu H'kHiiii.c i^ajp 

20 b y inv okin g the up f mKtion of thr rr^miirc r ^frr^nro objrrt If the re s our c e in not nrtirrr tiy 
up, the resourcejra^jdn g^ystem the watch for resource state for this resource and 

nojaty clients that the resource is down. In step 1407, the function adds the client object to 
- list of the resource reference object by invoking the atfrHtinction of the resoufce 

reference object ^Jji-gfrpp !4uS the rnncrion initialises the client oh)ecf liy invnl-inp; Tbg^mt 

25 -fiiotiiiH^o^ reference object passing die client object and then re teas^ 

Figure 15 is a flow diagram of the example implementation of the 
Directory: :res!sUp function. This function is passed the context of a resource (e.g., a pointer 
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to a resource reference object for the resource) and sets the corresponding resource reference 
object to indicate that the resource is up. This function is invoked by the resource manager 
to notify the resource tracking system that the resource is up. In step 1501, the function 
retrieves a pointer to the resource by invoking the findRefRes function of this directory 
object passing the context. In step 1502, if a resource reference object was found, then the 
function continues at step 1503, else the function returns an error indication. In step 1503, 
the function invokes the up function of the resource reference object to notify the clients that 
the resource is up. The function then returns. The Directory: :resIsDown function operates 
in an analogous manner except that the down function of the resource reference object is 
:io invoked in step 1503. 



pi Figure 16 is a flow diagram of an example implementation of the 

m 

jj. Directory: :busStateChanged function. This function is invoked by the resource manager to 

^ indicate that the state of the bus has changed. In step 1601, the function selects the next 

O resource reference object in the resource reference list. In step 1602, if all the resource 

m 

pyi5 reference objects have already been selected, then the function returns, else the function 
^ continues at step 1603. In step 1603, if there is a client object in the client list of the selected 
s resource reference object, then the function continues step 1604, else the function loops to 
step 1601 to select the next resource reference object. In step 1604, the function reference 
counts the resource reference object by invoking the AddRef function. In step 1605, the 
20 function invokes the up function of the selected resource reference object to notify the client 
objects that the resource is up. If the bus is down, the up function will be unable to locate 
the resource and cause the resource tracking system to enter the watching for resource state. 
In step 1606, the function invokes the release function of the resource reference object to 
decrement the reference count and loops to step 1601 to select the next resource reference 
25 object. Two other functions of the directoiy object operate in an analogous manner. The 
resetRef function performs the same processing except that in the step 1605 the function 
invokes the down function of the resource reference object after the up function is invoked. 
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This resets all the references to the resources to the down state. The clearlnitialBlock 
function also performs the same processing except that in step 1605 the function invokes the 
clearlnitialBlock function, rather than the up function, which processes the events in the 
message queue (described below) of the resource reference objects. The resource manager 
5 invokes this function after a client resource is activated so that the client resource can start 
processing events. 

Figure 17 is a flow diagram of an example implementation of the 
Directory: :findRefRes function. This function is invoked passing the name of a resource. 
B The function returns the resource reference object corresponding to that name. In step 1701, 

yio the function selects the next resource reference object in the resource reference list. In 

fU" 

fO step 1702 if all the resource reference objects have already been selected, then the function 

f£ returns an error indication, else the function continues at step 1703. In step 1703, if the 

W passed name matches the name of the selected resource reference object, then the function 

O reference counts the resource reference object and returns a pointer to that resource reference 

m 

pji5 object, else the function loops to step 1701 to select the next resource reference object. The 

m 

^ directory object has another function with the same name that operators in an analogous 
^ manner except that it is passed a context of (e.g., pointer to) the resource reference object 
rather than the name. 

Figure 18 is a flow diagram of an example implementation of the 
20 Directory ::goingA way function. This function is passed a resource reference object and 
performs the processing to indicate that the resource reference object is going away, that is, 
the last client is unregistering its interest in the resource. In step 1801, if there are client 
objects on the client list of the passed resource reference object, then some client objects are 
waiting to be deleted and the resource cannot go away and the function returns, else the 
25 function continues at step 1802. In step 1802, the function removes the resource reference 
object from the resource reference list. In step 1803, the function retrieves a reference 
counted pointer to the resource by invoking the getRefCountedPtr function of the resource 
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reference object. In step 1804, if a reference counted pointer was retrieved, then the resource 
is up and the function continues at step 1805, else the function continues at step 1807. In 
step 1805, the function releases the resource by invoking its Release function. In step 1806, 
the function invokes the stopMonitoringRes function passing the resource reference object to 
notify the resource manager to stop monitoring for the resource to go down. In step 1807, 
the function invokes the stopWatchingRes function passing the resource reference object to 
notify the resource manager to stop watching for the resource to come up. In step 1808, the 
function releases the resource reference object by invoking the Release function of the 
resource reference object and then returns. 

Figure 19 is a flow diagram of an example implementation of the watchRes function. 
The function is passed a reference object and places a watch on the resource. In steps 1901- 
1903, the function loops determining whether that resource is already in the tracked resource 
list (e.g., watched resource table). In step 1901, the function selects the next resource in the 
tracked resource list. In step 1902, if all the resources have already been selected, then the 
function continues at step 1905, else the function continues at step 1903. In step 1903, if the 
selected resource matches the passed resource, then the function continues in step 1904, else 
the function loops to step 1901 to select the next resource. In step 1904, the function sets the 
entry for that resource to being watched and returns an indication of a duplicate watch. In 
step 1905, the function adds an entry to the tracked resource list that points to the passed 
resource reference object. In step 1906, the function sets the entry for that resource to being 
watched and returns. The stopWatchingRes, monitorRes, and stopMonitoringRes functions 
operate in an analogous manner. Further implementations of these functions are described 
below. 

B. Resource Reference Object 

Figures 20-30 are flow diagrams illustrating the processing of the functions of 
the resource reference objects. Figure 20 is a flow diagram of an example implementation of 
the ResRef::sendEventAndProcess function. This function is passed an event and a 
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parameter and places the event and parameter on the message queue for the resource 
reference object and then processes the event and parameters that are on the queue. The 
event can be an indication that the resource is up or down or is being initialized. In 
step 2001, the function puts the event and the parameter on the message queue for the 
resource reference object. In step 2002, if another thread is processing messages for this 
resource reference object, then the function returns, else the function continues at step 2003. 
In step 2003, the function sets a processing flag to true. In step 2004, the function invokes 
the processEventsAndFreeLock function of this resource reference object to process the 
messages in the message queue. 

Figure 21 is a flow diagram of an example implementation of the 
ResRef::processEventsAndFreeLock function. This function loops retrieving messages from 
the message queue for this resource reference object. The function determines the type of 
the message and performs the necessary processing. In step 2101, if this resource reference 
object is already processing a message (e.g., invoked by another thread), then the function 
returns, else the function continues at step 2102. In step 2102, the function retrieves a 
message from the message queue. In step 2103, if all the messages have already been 
retrieved, then the function continues at step 2109, else the function continues at step 2104. 
In steps 2104-2105, the function determines whether the retrieved message indicates that the 
resource is up or down, or is being initialized. In steps 2106-2108, the function invokes the 
appropriate function (i.e., processResIsUpMsg, processResIsDownMsg and 
processResInitMsg) of this resource reference object to process the retrieved message. The 
function then loops to step 2102 to retrieve the next message from the message queue. In 
step 2109, the function sets the processing flag to false. In step 2110, the function invokes 
the clearClients function of this resource reference object and returns. The clear clients 
function deletes any client objects whose delete flag is set. 

Figure 22 is a flow diagram of an example implementation of the ResRef::Init 
function. This function is passed a client .object, and in step 2201, the function places a 
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message on the message queue of this resource reference object to initialize that client. The 
function then returns. 

Figure 23 is a flow diagram of an example implementation of the 
ResRef::processResIsUpMsg function. This function is invoked when a message indicating 
that the resource is up is retrieved from the message queue. In step 2301, the function 
invokes the findRes function of the directory object to retrieve a pointer to the resource. The 
findRes function is supplied by the resource manager. In step 2301, if a pointer to the 
resource is returned, then the resource is up and the function continues at step 2304, else the 
resource went down since the up message was generated and the function continues at 
step 2303. In step 2303, the function notifies the resource manager to start watching the 
resource to come up by invoking the watchRes function of the directory object passing this 
resource reference object and then returns. In step 2304, the function retrieves the created 
time of the resource. In step 2305, if the pointer to the reference in the reference resource 
object is null (which may mean that this resource reference object recognized that the 
resource was down) or the created time of the resource is not equal to the created time 
indicated in this resource reference object (which may mean that a new occurrence of the 
resource has been instantiated), then the function continues at step 2306, else this reference 
resource object already has the correct pointer to the resource and the resource is already 
being monitored so the function returns. In step 2306, if this resource reference object has a 
pointer to the resource, then the pointer is out-of-date and the function continues at 
step 2307, else the function continues at step 2308. In step 2307, the function sets the 
resource pointer in this resource reference object to null, notifies the client objects that the 
resource is down by invoking the tellClientsResIsDown function, directs the resource 
manager to stop monitoring the resource, and sets the created time for the resource to zero. 
In step 2308, the function directs the resource manager to stop watching the resource by 
invoking the stopWatchingRes function of the directory object. In step 2309, if the 
stopWatchingRes invocation was successful, then the resource is up and the function 
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continues at step 2311, else the function continues at step 2310. In step 2310, the function 
directs the resource manager to start watching the resource by invoking the watchRes 
function of the directory object and then returns. In step 23 1 1, the function sets the resource 
pointer to point to the resource provided in step 2301, sets the created time of this resource 
reference object to the new created time, and directs the resource manager to start monitoring 
the resource by invoking the monitorRes function of the directory object. In step 2312, if the 
start of monitoring is successful, then the function continues at step 2313, else the function 
continues at step 2314. In step 23 13, the function notifies the client objects that the resource 
is up by invoking the tellClientsResIsUp function and returns. In step 23 14, the function 
records that the resource is down by setting the resource pointer to null and setting the 
created time to zero for this reference resource object and returns. 

Figure 24 is a flow diagram of an example implementation of the 
ResRef::processResIsDownMsg function. This function is invoked to process the resource 
down message that is retrieved from the message queue. In step 2401, if this resource 
reference object points to a resource, the function continues at step 2402, else the resource 
reference object already indicates that the resource is down and the function continues at 
step 2409. In step 2402, the function requests the resource manager to supply a resource 
pointer by invoking the findRes function of the directory object. In step 2403, if the pointer 
to the resource is supplied, then the resource is now up and the function continues at 
step 2404, else the function continues at step 2408 to indicate that the resource is really 
down. In step 2404, the function retrieves the created time of the resource. In step 2405, if 
the created time of the resource is equal to the created time stored in the resource reference 
object, then the function continues at step 2406, else the reference to the resource is out-of- 
date because the resource went down and has already come back up and the function 
continues at step 2408 to indicate that the resource went down. In step 2406, the function 
sets the resource reference object to point to the resource and directs the resource manager to 
start monitoring the resource by invoking the monitorRes function of the directory object. In 



[305 8 1 -8002/Application.doc] 



33 

step 2407, if the start of monitoring was successful, then the function returns, else the 
function continues at step 2408. In step 2408, the function sets the resource pointer of this 
resource reference object to null, notifies the client objects that the resource is down by 
invoking the tellClientsResIsDown function, directs the resource manager to stop monitoring 
the resource by invoking the stopMonitoringRes function of the directory object, and sets the 
created time of the resource to zero. In step 2409, the function simulates the receiving of a 
resource up message from the application by invoking the processResIsUpMsg function. 
That invocation will start watching the resource if it is not up and start monitoring the 
resource if it is up. 

Figure 25 is a flow diagram of an example implementation of the 
ResRef::processingClients function. This helper function is passed an indication of which 
function of the client objects to invoke. The function loops selecting each client object and 
invoking that function. In step 2501, the function loops selecting each client object in the 
client list. In step 2502, if all the client objects in the client list have already been selected, 
then the function returns, else the function continues at step 2503. In step 2503, if the 
selected client object is marked to be deleted, then the function loops to step 2501 to select 
the next client object, else the function continues at step 2504. In step 2504, the function 
invokes the function indicated by the passed parameter. In step 2505, the function sets the 
selected client object to active which indicates that client has already processed a message 
and knows the state of the resource and then loops to step 2501 to select the next client 
object. The function allows client objects to be added while processing. The function sets a 
didProcess flag in each client object as it invokes the function. The function loops through 
the client list until it detects that the function for all the client objects have been invoked. 
Upon completion, the function clears all the didProcess flags for when it is next invoked. 

Figure 26 is a flow diagram of an example implementation of the ResRef::up 
function. This function is invoked by the directory object to indicate that the resource is now 
up. In step 2601, the function places an up event on the queue by invoking the 
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sendEventAndProcess function and then returns. The ResRef::down function operates in an 
analogous manner. 

Figure 27 is a flow diagram of an example implementation of the ResRef::add 
function. This function is passed a client object and adds that client object to the client list 
of this resource reference object. In step 2701, the function adds the passed client object to 
the client list. In step 2702, the function sets the client object to point to this resource 
reference object. 

Figure 28 is a flow diagram of an example implementation of the 
ResRef::goingAway function. The function is passed a client object. In step 2801, the 
&jjio function invokes the AddRef function of this resource reference object to indicate that the 
Hi function is accessing this object. In step 2802, the function removes the passed client object 

is? ; 

py from the client list. In step 2803, the function invokes the goingAway function of the 



5 



q directory object to notify the directory object that this reference resource object is going 

i 
m 

£3 15 object and then returns. If another thread is currently processing messages from the queue, 



away. In step 2804, the function invokes the Release function of the resource reference 



) then this resource reference object cannot yet be deleted and the function marks the passed 
client object to be deleted and returns a failure indicator. 

Figure 29 is a flow diagram of an example implementation of the 
ResRef::getRefCountedPtr function. This function returns a reference counted pointer to the 
20 resource. In step 2901, if the resource reference object points to a resource, then the function 
continues at step 2902, else the function returns. In step 2902, the function reference counts 
the resource by invoking the AddRef function of the resource and then returns the referenced 
counted pointer. 

Figure 30 is a flow diagram of an example implementation of the 
25 ResRef:: delete Yourself function. In step 3001, the function removes this resource reference 
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object from the resource reference list of the directory object. In step 3002, the function 
reference counts the resource reference object by invoking the AddRef function. In steps' 
3003-3005, the function loops selecting each client object in the client list and requesting 
that they delete themselves. In step 3003, the function selects the next client object in the 
client list. In step 3004, if all the client objects have already been selected, then the function 
releases the resource reference object by invoking the release function in step 3006 and then 
returns, else the function continues at step 3005. In step 3005, the function requests the 
selected client object to delete itself by invoking the delete Yourself function and then loops 
to step 3003 to select the next client object. 

C. Client Object 

^Ei gmi 31 3' 1 llii flow diagmms illustrating tin piucei^iilg of die f u ii ol ionirpf 
tjjp rlipnt object Figure ^ k a f l ow diagram - of an example implementation of the 

step 3101, the functioniels-4he4^ pointer ot this client object to null. In step 3102, 
the fijnetiXmretrieves a reference counted pointer to the resource by invoking the 
ytPpfTminte dPtT fnn r tirm of th e rngnnrnn rpfpTnn fte_nhj ect and saves it ii? a smart ^M Mttter 
In step 3103, if the client object has an interface identifier specifiec^Jl^^ 
continues at step~3lU4, else the function continues at step 3105. In step 3105, the function 
r etrieves a pomtgjila4he interface by invoking the query i nterface function of the resourc e. 
In ^step-3405rThfe" function notif ies^the client derivation thatthe~7esour^ 

yokin g thft rPS^ir M<f T T p ^"Ct 1 ^ prmHHfH hy th^ ^lifnt The function then returns*. 



Figure 32 is a flow diagram of an example implementation of the 
Client: :resIsDown function. This function is invoked when a resource goes down. In 
step 3201, the function sets the pointer to the resource for this client object to null. In 
step 3202, the function notifies the client that the resource is now down by invoking the 
resourcelsDown function proVided by the client. The function then returns. 
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. Figure— 33 — is a fl o w — diagi ' tUit uf an txamplo implementation 
Client: :delete Yourself function. This function is invoked when this cliejit-obteeris'To be 
deleted. In step ^Qi^tVip fhnptipn rlHa^^hf^ryff^F^ identifier of this client object In 

^tep^Q2 T ^Thi g rhnnf nWy t A luk U rpfprpnrp tn a rpcmirrp rpfprpnrp nh yu i Hu n- f lip 

function continues at step 3303, else the function continues at step 3308. In step 31Q^uie 
function notifies the resoms^a^fereirceTflyect that this client is going away by invoking to be 



;Away fjinf-tmrL — In stop 3304, if lliu ' T HVO'ca tiOli is successful, then 
contin ue s at step 330 57- else llie functio n contin ues at step 3306. In step 3305 




■4herfnnctkm 
— the functio n 



decrements the reference count for in the resource reference object and sets its pointer to 
muffin ^p^2£^i t hp fiirintinn note thp HpWp flag gf ft^n r l i r nt ob jrr t^ 7TTnir" fir-tke^ 
f 9 if this client object has a-re fcrcnoc to a resource reference object, then -the~ 
gtion returns, else the function continues at st epJ&Qft — In step 3308, the function 
estmctsJliis-Glieilt object and remmsr-' 




^-Eigure — 34 is a — fkrw — diagram — of — exampl e — implem entation — of — the 
- €licnt ::r csourceIsUp function. This function is provided by a client to specify client spec i f ic 

p rnr.pssjpp f 0 fa performed when n r^SOUr^f entries lip In gtp p thiQ fhnptir t n gpfx a 

ffl resource is a flag for the client. Th e cli e nt al s o provides an analogous function for when a 
resoiute goes duwn. 

2. Watching a Resource 

20 Figures 35-44 are flow diagrams illustrating the example implementations of 

functions for watching a resource. 

A. Watch Resource Component 

^^j^x^ ^Fjgiii£s35-3^ diagrams of functions of resource manager for watclung 

— resou r ce. Tigiue 33 is a flow diagram of an example imple ment ati on uf -the- ResourceUp 
25 junction o f the rff i rn i rrr i im i i ii ^ i Tht* mrmrrr rnnn^P i i nvnlrr r-f h r. f u nction whcnfi Yftr f i 
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r esource at -tirat~TTorie is^flete cted as he i ng up. — ¥ hc i c s oui cc "m anager may fam w thafc -a. 
^rmrnpj^ became it - ^ rmiT'rtll^l-f hn ornatinn nf thr r- regoiircfl at r , tartnp n h e canr . e i t 
dynami cally crea te d thp Tfrnonrrt 1 whon rpqnpitod by a n ot he r rf.Mnni'i 1 , in brr ause another 
xpSOpree t reate d that r n ani ir cc and r cgis f e r e. i l (Iil umlnl i t is o ti ii ^. wil.1l th e resoiirCE--manager r 
^<Chis function is passed a p ointer tft foe rr<rrmrnp thatk nn w up Tri step , if thn him ifr * 

^pp, thqn the f j»efaoiL4lQtifie s^ the busjn^nager by invoicing the attach functi o n uf Qic bU J j 
■ ^mariagAr pac in g thp iHpttfjf j cation of the resourc e- that i c now ^ttp- etse - the functio n- returns , In- 
^ste p 3502 r the fu n cti on llpri n tn th e 1o i . i l i ' s i n m H ^ f tirer.tft i y tn jpd^ atp tW * h <* y j m p rl 
resource is Up. T he fnnctinn thon rnfiirn^ 

Figure 36 is a flow diagram of an example implementation of the 
ResourceDown function of the resource manager. The resource manager invokes this 
function passing the identification of a resource that has gone down. In step 3601, if the bus 
is up, then the function notifies the bus manager by invoking the detach function of the bus 
manager passing an indication of the resource that is now down, else the function returns. In 
step 3602, the function updates the local resource directory to indicate that the resource is no 
longer up. The function then returns. 

Figure 37 is a flow diagram of an example implementation of the 
Directory: :watchRes function. This function is implemented by the resource manager and is 
invoked by a client to notify the resource manager to start watching a resource. This 
function is passed the identification (e.g., name) of the resource. In steps 3701-3703, the 
function loops checking whether the client node is already watching that resource. In the 
step 3701, the function selects the next entry in the client watched resource table starting 
with the first. In step 3702, if all the entries have already been selected, then the function 
continues in step 3704, else the function continues at step 3703. In step 3703, if the selected 
entry indicates that the passed resource is already being watched by the same client, then the 
function returns an indication that a duplicate watch has been placed on this resource by the 
client, else the function loops to step 3701 to select the next entry. In step 3704, the function 
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updates the client watched resource table to indicate that the client is watching the resource. 
In step 3705, if the resource is already being watched by the client node (because of a watch 
placed on that resource by another client), then the function returns, else the function 
continues at step 3706. In step 3706, if the bus is up, then the function notifies the bus 
manager to start watching the resource by invoking the watchRes function of the bus 
manager passing the identification of the resource to be watched. The function then returns. 
The passed pointer is passed to the bus manager as a notification context. 

Figure 38 is a flow diagram of an example implementation of the 
Directory:: stop WatchingRes function. This function is implemented by the resource 
manager and is invoked by a client to notify the resource manager to stop watching a 
resource. The function is passed the identification of the resource. In steps 3801-3803, the 
function searches for an entry corresponding to the resource and client in the client watched 
resource table. In step 3801, the function selects the next entry in the client watched 
resource table starting with the first. In step 3802, if all the entries have already been 
selected, then the client is not watching the resource and the function returns an error, else 
the function continues at step 3803. In step 3803, if the selected entry corresponds to the 
watch on the resource for the client, then the function continues at step 3804, else the 
function loops to step 3803 to select the next entry. In step 3804, the function removes the 
selected entry from the client watched resource table to indicate that the client is no longer 
watching the resource. In step 3805, if other clients at that node are still watching the 
resource, then the function returns, else the function continues at step 3806. In step 3806, if 
the bus is up, then the function notifies the bus manager to stop watching the resource by 
invoking the stopWatchingRes function of the bus manager passing an indication of the 
resource. The function then returns. 

Figure 38A is a flow diagram of an example implementation of a 
watchResIsUp function of the resource manager. This function is invoked by the bus 
manager when a resource that is being watched comes up. This function is passed the 
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context of the resource that is now up. In step 38A01, the function locates the context for the 
resource that is now up. In step 38A02, the function invokes the resIsUp function of the 
directory object to notify the clients. The function then returns. 

Figure 39 is a flow diagram of an example implementation of the 
ClientProcessIsDown function of the resource manager. The resource manager invokes this 
function whenever it detects that a process at the client node has gone down. This function 
performs processing to indicate that each resource of the process is now down. The resource 
manager maintains a list of resources per process in a process/resource list. In step 3901, if 
the bus is up, then the function notifies the bus manager that the resources of the process are 
now down by invoking the detach function of the bus manager for each resource in the 
process, else the function returns. In step 3902, the function invokes the 
Directory: :stopWatchingRes function for each client within that process that was watching a 
resource as indicated by the client watched resource table. The function also updates its 
tables and returns then returns. 

B. Bus Manager 

Figures 40-44 are flow diagrams of functions of the bus manager. Figure 40 is 
a flow diagram of an example implementation of the attach function of the bus manager. The 
attach function is invoked by nodes to notify the bus manager that a resource located at that 
node is now up. This function is passed an identification of and a pointer to the resource. In 
step 4001, the function updates the resource directory to indicate that the identified resource 
is now up and stores a pointer to that resource. In step 4002, if this resource is being 
watched, then the function continues at step 4003, else the function returns. The function 
determines whether a resource is being watched by searching the watched resource table of 
the bus manager. In step 4003-4005, the function loops notifying the client nodes which are 
watching the resource that the resource is now up. In step 4003, the function selects the next 
watching node that is watching for that resource from the local watched resource table. In 
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step 4004, if all the watching nodes have already been selected, then the function returns, 
else the function continues at step 4005. In step 4005, the function notifies the selected 
watching node that the resource is now up by invoking the watchResIsUp function of the 
watching node. The function then loops to step 4003 to select the next watching node. 

5 Figure 41 is a flow diagram of an example implementation of the detach 

function of the bus manager. The detach function is invoked by nodes to notify the bus 
manager that a resource located at that node is now down. This function is passed an 
indication of the resource. In step 4101, the function updates the resource directory to 
O indicate that the resource is no longer up and then returns. 

fyio Figure 42 is a flow diagram of an example implementation of the watchRes 

gj function of the bus manager. This function is invoked by a client node and is passed the 
5 1 identification of the resource to be watched along with a pointer to an interface of the client 
|L node. The bus manager invokes the function watchResIsUp of the interface to notify the 
j=n client node when the resource comes up. In step 4201, the function adds an entry to the local 
£015 watched resource table for the passed resource and client node. In step 4202, if the resource 
(?! is already up as indicated by the resource directory, then the function continues at step 4203, 
else the function returns. In step 4203, the function notifies the client node that the passed 
resource is up by invoking the watchResIsUp function of the client node passing the 
identification of and a pointer to the resource. The function then returns 

20 Figure 43 is a flow diagram of an example implementation of the 

stopWatchingRes function of the bus manager. A client node invokes this function to stop 
watching the passed resource. In step 4301, the function updates the watched resource table 
of the bus manager to indicate that the passed client node is not watching the passed 
resource. The function then returns. 
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Figure 44 is a flow diagram of example implementation of the nodelsDown 
function of the bus manager. The bus manager invokes this function whenever the bus 
manager detects that a node has gone down. In step 4401, the function invokes the detach 
function for each resource that was attached by the node that has gone down. In step 4402, 
the function invokes the stopWatchingRes function of the bus manager for all resources that 
were being watched by the node that has gone down. The function then returns. 

3. Monitoring a Resource 

Figure 45-52 are flow diagrams of example implementations of the functions of 
a client node and server node for monitoring a resource. 

A. Client Node 



-Figure 45 is — a flow diagram of an example — implemfiiitatioiL 



Directory::monitorRes function. This function is implemented] ^ the resoiu u^^nmg^er and 
is invoked by a client tostmtjiicawte^ resource to go down. In step 4501, 

the fuoGtktfTuses the passed resource to identify the server node (i.e., the node where the 

Source is locate d) for the re S ™ 1 *^ Th <* fnnntinn mny iiqp H i e ij ii H i y i iilni P^i ' H 'fi«ictinp_ of 

the resource to retrieve a pointer to an interface for identifying the server node. The fungi 
also updates the monitor resource table forthej^scausx-^^ client can be 

notified whexLlhe-fesource^oesdown and so that the server node can be re-notified if it goes 
do*tfn and comes up. In step 4502, if a connection has already been established with the 
server node asJadicated-by lhe Clienl coi mecl ion table, dicn the function coiitiuue s-ftt^ste^ 
4508, else the function continues at step 4503. In step 4503, the function establishes a 
connectioiiJa4th-ll^^ node by invoking the connectClient function of the server node 
Tassing a pointer to an interface of the client node for receiving notifications and passing a 
^nntevt for id entifying l l i k i ' nim eWit"i M. The invocntion rc trrrrnrrsefver contexts In 
step-45 04, if an enor is detected when invokingThe-eo nnectClient function, th efrthHiniCtion 



st£p-4 
dentin 



e ntinues at step 1505. .el se, the function continues at step 4506. In step^ SO^--lhe-fimctiQn3 
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:a9smr i££ that th e ? h server nndf- tWm vil iuifl p^ifln ii r. t in imnpintpj prm i ■ ■>■■■■■ imtlthrn 
-feterns: — In step 450 6, the functiotruptkrte s the clien fr- eoiniec i lon t ab i c to indicate that a 
^c onnection has now been est a bli c hed willi ser ver node with the client an d aei vei context. In- 
Instep 4507, the function signafe - lu slait sending a client is alive messa ge periodically t o the* 

Server node. The Sending nf { fa rMmt ir olivn mpQgfly nny ho nnnrpHpr^ fft frirm o£ 

' leasing" a resource. In step j4 5fl&^&fe-fene tioii invokes the monitor r eso urce fiinctintu Af^hft 
^rveT-rmde ^a^ ^ g the i d fT^'fi^™ 1 of the res o urce to be monitored^ The-fi mc i ion llien 
■returns 

Figure 46 is a flow diagram of example implementation of the 
Directory: :stopMonitoringRes function. This function is implemented by the resource 
manager and is invoked by a client to stop monitoring for the passed resource to go down. In 
step 4600, the function invokes the stop monitoring resource function of the server passing 
an identification of the resource. In the step 4601, the function updates the monitor resource 
table to indicate that the resource is no longer being monitored by the invoking client. In 
step 4602, if the client node is still monitoring a resource of the server node, then the 
function returns, else the function continues at step 4603. In step 4603, the function updates 
the client connection table to indicate that there is no longer a connection between the client 
node and the server node. In step 4604, the function signals to stop sending the client is alive 
message to the server node. When the server node does not receive this message during the 
next time period, the server node will update its server connection table to indicate that there 
is longer a connection. The function then returns. 

Figure 46A is a flow diagram of an example implementation of a 
processServerlsDown function. This function is invoked when the client node detects that a 
server node is down. In step 46A01, the function removes an entry for the server node from 
the client connection table to indicate that there is no longer a connection established with 
that server node. In steps 46A02-46A05, the function loops notifying clients that are 
monitoring a resource on the server node that the resource has gone down. In step 46A02, 
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the function selects the next resource of the server node. In step 46A03, if all resources have 
already been selected, then the function returns, else the function continues at step 46A04. 
In step 46A04, the function invokes the resIsDown function of the directory object. In step 
46A05, the function removes resource entry from the client monitor resource table. The 
5 function then loops to step 46A02 to select the next resource. 

Figure 47 is a flow diagram of an example implementation of a resIsDown 
function of the resource manager. This function is invoked by a server node to notify the 
resource manager that a resource that is being monitored has gone down. In step 4701, the 

p,: function invokes the resIsDown function of the directory object to notify the monitoring 

^ 10 clients and then returns. 

[IIS. 

irf i 

FU B. Server Node 

@0 

pj Figure 48 is a flow diagram of an example implementation of a connectClient 

L function of a server node. A client node invokes this function when it wants to start 

i=n monitoring resources at the server node. This function is passed a pointer to an interface of 

liU 

go 15 the client node which can be invoked by the server node to notify the client node when a 

41 

tfl resource has gone down. The function is also passed a client context that identifies this 
connection for the client. The function returns a server context. The combination of client 
context and server context uniquely identifies the connection. In step 4801, if the client node 
has a connection currently established with the server node as indicated by the server 

20 connection table, then the function continues at step 4802, else the function continues at step 
4803. The server node may have missed a message that indicated that the client node had 
previously gone down. In step 4802, the function performs the processing to indicate that the 
client node has gone down and then returns an error to the client node. When the client node 
receives this error message, it will again try to re-establish the connection and this time the 

25 server node will recognize that no connection is currently established. In step 4803, the 
function updates the server connection table to indicate that a connection is currently 
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established between the server node and client node and that the connection is identified by 
the server context and client context. The function then returns the server context to the 
client node. 

Figure 48A is a flow diagram of an example implementation of the monitor 
resource function of the server node. This function is passed an identification of the 
resource, an identification of the client node, and the current connection context for the 
connection between the client and server nodes. In step 48A01, if a connection is currently 
established with the client node, then the function continues at step 48A02, else the function 
returns are an error. In step 48A02, the function adds an entry indicating that the client node 
is monitoring the resource to the monitoring node table. In step 48A03, if the resource is 
currently up, then the function returns, else the function continues at step 48A04. In step 
48A04, the function removes the entry that was just added from the monitoring node table. 
In step 48A05, the routine invokes the resource is down function of the client node passing 
an indication of the resource. In step 48A06, if an error was detected in notifying the client 
node that the resources down, then the function continues at step 48A07, else the function 
returns. In step 48A07, the function assumes that the client node is down and performs the 
appropriate processing. The function then returns. 

Figure 48B is a flow diagram of an example implementation of the stop 
monitoring resource function of the server node. The function is passed an identification of a 
resource and the current connection context for the connection between the client and server 
nodes. In step 48B01, if a connection is currently established with the client node, then the 
function continues at step 48B02, else the function returns an error. In step 48B02, if there is 
an entry in the monitoring node table corresponding to the monitoring of this resource by the 
client node, then the function continues at step 48B03, else the function returns an error. In 
step 48B03, the function removes the entry from the monitoring node table and then returns. 
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Figure 49 is a flow diagram of example implementation of the clientlsAlive 
function of a server node. This function is invoked by a client node and is passed the 
identification of the connection, that is a combination of client context and server context. In 
step 4901, if the client is in the client table, then the function resets the keep alive timer for 
that client and returns, else the function continues at step 4902. In step 4902, the function 
assumes that in the client node has gone down and returns an error message to the client 
node. 

Figure 50 is a flow diagram of an example implementation of the resIsDown 
function of a server node. This function is invoked when it is detected that a resource has 
gone down at the server node. This function notifies each client node that has requested to 
monitor that resource. In step 5001, the function selects the next client node from the 
monitoring node table that is monitoring that resource. In step 5002, if all the client nodes 
have already been selected, then the function returns, else the function continues at step 
5003. In step 5003, the function invokes the resIsDown function of the client node using the 
pointer to the client node stored in the server connection table passing the identification of 
the resource that is now down. In step 5004, if an error is detected in the invocation, then the 
function continues at step 5005, else the function loops to step 5001 to select next client 
node. In step 5005, the function assumes that the selected client node has gone down and 
updates the server connection table and the monitoring node table and simulates that it 
received a resource is down message for each resource on the client node that is being 
maintained by the server node and loops to step 5001 to select the next client node. 

Figure 51 is a flow diagram of an example implementation of a 
noKeepAliveReceived function of the server node. This function is invoked when the server 
node detects that no keep alive message has been received from a certain client within the 
time. In step 5101, the function assumes that the client has gone down and updates the 
server connection table for that client. The function then returns. 
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Figure 52 is a flow diagram of an example implementation of the 
processClientlsDown function of a server node. In step 5301, the function removes the entry 
for the client connection from the server connection table. The function then returns. 



4. Property Notifications 

^ Hio - traolung system alse - piuvid ES for w aicliing - t h e - properties~of - server 
^j-esgUr cfe by a client resource. A proper l y of a resource cSirespe nds - to - data related to- the 
jgso urce whose v a hie can he set by that resource during evprntinn nf n fiinrt i nn nf the 
resource That fu nc tion ca n ftp involved by nn rt th p r ' T^ftwnr'* ^mf^^ T he function may 
be specifically provided to set the value of the property (e.g., a set propertyjjinetron) or may 




y 

in 



ho set the value of the property as a side effect. In one_ 



timent, a property watching 



component of the resouixejiackiflg-s^^ client resources to register their interest in 

ing notifications when a property of a server resource is set. The client resources also 
specify the^ghav ior to be pufui m c d wheit lit e property i s se t. — The property wa tching 

component provides a synchronous mechanism for notifying client resources wlien-^the 

&i - — — 

HU 15 property is set. This sync hronous mech ^ism ^g^i^H^Tr' 77 ^^ who are 

registered~t6~watch a property are notified of the setting of the property before any client 
resou rces are notified of a subsequent setting of t he pr oper ly. The^ p roperty watc hing 

COmpcmentjlm ^ a mec h anism for Qynrhrnniymg prnrpcHng m urin g hr plp rhpnf 

^resources: — • 



20 Figure 53 is a block diagram illustrating the communications between a server 

resource and a client resource when watching a property. When a client resource wants to 
watch a property of a server resource, the client resource registers to track the server resource 
as described above. When the server resource enters the up state, the client resource can 
then register to watch a property of the server resource. The client resource invokes a watch 

25 property function of the server resource passing the name of the property to be watched, an 
identification of the client resource, and a context of the client resource that uniquely 
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identifies that property to the client resource. When the property of the server resource is 
set, the server resource invokes a property set function of the client resource passing the 
context received from the client resource and passing the value of the property. The property 
set function of the client resource can then use the context to identify the property and 
5 perform the behavior specified when the client resource specified its interests in watching the 
property. When the client resource no longer needs to watch the property, the client resource 
invokes the stop watching property function of the server resource. The server resource 
registers to monitor each of its client resources so that when a client resource goes down, the 
server resource receives a resource is down notification. Upon receiving such a notification, 
□ 10 the server resource stops notifying the client resource when the property is set. In one 

y embodiment, a client node may cache property values so requests to get the value of that 

jlJ 

|£i property can be satisfied locally. 

if! 

jij Figure 54 is a block diagram of the components to support the watching of 

1^ properties by a client resource. In one embodiment, the property watching component of a 

less? 

kjj 15 client resource uses the directoiy object 5401, resource reference object 5402, and client 
ffl object 5403 data structures that are used for tracking a resource. When a property of a server 
iQ resource is being watched, a special type of client object is added to the list of client objects 
of the resource reference object for that server resource. The special type of client object 
indicates that it represents the watching of a certain property and includes a property 
20 reference object 5404 for each time that the client resource has registered to watch that 
property. Each property reference object has a function that is to be invoked when the 
property is set to notify the client resource. The context/client table 5405 contains an entry 
for each property of a server resource that is being watched by that client resource. Each 
entry contains a context and a property client indicator. The context uniquely identifies the 
25 server resource and property within the client resource, and the property client indicator 
points to the corresponding property client object. A client resource also includes a 
synchronize property function 5406 and a property set function 5407. The synchronize 
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property function is invoked by the server resource when a client resource first registers to 
watch a certain property of that server resource to provide the current value of the property to 
the client resource. The property set function is invoked whenever a watched property is set. 
These functions are passed the context and the property value and perform the behaviors 
registered by the client resource. 

Figure 55 is a block diagram illustrating the components to support the 
watching of properties of a server resource. The server resource 5501 includes a 
property/client table 5502. The property/client table contains an entry for each property of 
the server resource that is being watched. Each entry contains the name of the property, the 
value for that property, and a client watching object 5503 for each client resource that has 
registered to watch that property. Each entry may also include a queue for storing property 
values in the order in which they are set pending notification of each of the client resources. 
The server resource also includes a watch property function 5504 and a stop watching 
property function 5505. The watch property function is passed an indication of a property of 
the server resource, the identification of the client resource, and a context. The watch 
property function adds a client watching property object in the property/client table to 
indicate that the client resource is now watching the property. The watch property function 
also requests that the client resource to be monitored using a monitoring component 5506. 

- \Add - MunRcsIsDownBlock to Figure] r 

Figure 56 is a flow diagram of an example implementation of the watch 
property function of the server resource. This function is passed the name of a property, a 
reference to the client resource requesting to watch the property, and a context used to 
identify the watch within the client resource. In step 5601, if the server resource is already 
monitoring the client resource, the function continues at step 5603, else the function 
continues at step 5602. In step 5602, the function invokes the register resource function 
passing an indication of the client resource to register for tracking the client resource and 
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receiving in return a handle for identifying that registration. In general, a server resource will 
only receive one watch property invocation for each property that a client resource registers 
an interest. The monitoring of the client resource may be performed using the watching and 
monitoring components of the resource tracking system as described above or may be 
5 performed using a monitoring component that is adapted for specifically monitoring client 
resources that are watching a property. In step 56Q3, the function adds an entry into the 
property/client table for the client. In step 5604, the function retrieves the property value for 
that property. In step 5605, the function invokes the synchronize property function of the 
client resource passing the context and the retrieved property value. The function then 
Q 10 returns. 

h i 

|^ Figure 57 is a flow diagram of an example implementation of the stop watching 

S property function of the server resource. This function is passed the name of a property and 
ry an indication of the client resource. In step 5701, the function removes the client watching 
q object for that client resource for that property from the property/client table. In step 5702, if 
^! 15 the property/client table contains no more client watching objects for that client resource, 
S then the function continues at step 5703, else the function returns. In step 5703, the function 
a invokes the unregister resource function to stop monitoring that client resource. The function 
then returns. 

Figure 58 is a flow diagram of an example implementation of the monitor 
20 resource is down function of the server resource. This function is passed the identification of 
the client resource that is down. In step 5801, the function removes all client watching 
objects for the client resource from the property/client table. In step 5802, the function 
unregisters monitoring of that client resource and then returns. 

Figure 59 is a flow diagram of an example implementation of the set property 
25 function of the server resource. The set property function of the server resource is passed the 
name of the property and a value. This function adds the property value to a queue for that 
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property and then processes the values in the queue to notify the client resources. In step 
5901, the function updates the property value in the property/client table and adds the 
property value to the queue for that property. In step 5902, if that property queue is being 
processed to by another thread, then the function returns, else the function continues at step 
5903. In step 5903, the function sets a property queue is being processed flag to indicate that 
this thread will begin processing the queue for this property. In step 5904, the function 
invokes the process queue function to process the queue for this property. In step 5905, the 
function clears the property queue is being processed flag and then returns. In one 
embodiment, each property has an object associated with it that provides the functions and 
data structures for managing and processing the queue. 

Figure 60 is a flow diagram of the process queue function. The process queue 
function loops selecting each value in the queue for a property and notifying each client 
resource that is watching that property. In step 6001, the function selects the next value in 
the property queue. In step 6002, if the queue is empty, then the function returns, else the 
function continues at step 6003. In steps 6003-6007, the function loops notifying each client 
resource who is watching the property. In step 6003, the function selects the next client 
resource of the property as indicated by the client watching objects. In step 6004, if all the 
client resources have already been selected, the function loops to step 6001 to select the next 
value in the property queue. In step 6005, the function invokes the property set function of 
the selected client resource passing the context and the value for the property. This function 
is a synchronous invocation so that it does not return until the client resource performs its 
behaviors associated with this property. In step 6006, if an error is returned, then the client 
resource is assumed to be down and the function continues at step 6007, else the function 
loops to step 6003 to select the next client resource of the property. In step 6007, the 
function invokes the monitor resource is down function passing the client resource and then 
loops to step 6003 to select the next client resource of the property. 
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A^gx^ ^Ei guro 61 ia q flow diagram of an - cxomp l c TiwplfeiTlfeiltat hjii of a register wat ch 

^V^ 00 ^^ filiation of a client rpSfVir™* This ^Tl^On is p^gerl iHgntifipitinn nf ttipugnn/or ^mir fl A 

Jhe -name o f the property lo be waldied, and ide ntification of the client resource: — fe-step^_ 

101, if thf> rlT^nT^cnTirr ^ n nlrnnrly nrntnhing ri i a t pre i p^rfy thpn tliP* functi on COntinU£ S^at 

5 ste^6106, else the function continues at step 6102. In step 6102, the function creates a 
unique coittextfcr the client resource and property. Tn step thp fnnr.ijnr i invnfrgg rtift 
watch property function of the server resource passing the name of the property and the 



context, in step 6104, the function creates a property client object for that property and adds 
\ that object to th e client object list of the resource reference object for that resource. In step 
Q 10 6105, the functioiPaH^ to thg j^te jd/ piu paiy table. In Step oluo, tuncno"? 

y proprny rr fii' Min uliju I h i l ln 1 i . 1 ;iT i O< L i;i l Hl ui l h l i l t pr o p o rty rli r nt nhjent 



ioiTadcis a 
and they 



py Figure 62 is a flow diagram of an example implementation of the property set 

j~l function of the client resource. This function is passed a context and a property value. In 
^;i5 step 6001, the function retrieves the pointer to the property client object from the 
03 context/client table using the passed context. In step 6202-6204, the function loops invoking 
the behavior associated with each property reference object for that property client object. In 
step 6202, the function selects the next property reference object starting with the first. In 
step 6203, if all the property reference objects have already been selected, then the function 
20 returns, else the function continues at step 6004. In step 6004, the function invokes the value 
set function of the property reference object to notify the client resource that the property has 
been set. The function then loops to step 6202 to select the next property reference object. 

5. Event system 

^p^^^>^ jL* i± hf> " A/fin t syf ft p ™ provides q m^^icm fr>r p tv^ n^ing fy^ n t notifications whe n 

*55 events are generated by resour c e An ^^nt i p nn ngynohrn i inw - Q i annl thnt \r Hirtrinii fr»d=tn 
client resources, flko referred tn ir, liotrwrq who have rngir . tnr r .d tn listen for nn nv errP" 
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^ jijgiaL In one embodiment, thc - c v eiit sytileiu ne ither gua rantees that q listener will rec eive 

thg_eyents4 n - 4 l ic u idci they are geneiated nor guarantees that caeh li sten er will roe eive-e^gry 

^ey rnt for Avh irh it in limn i ng Farh rvrn t h as a n nno i' ii il r i l \ vrn l l ypp A lftf fnfr registers 

to listen for events of a certain event type.Inj)n&jex»k^ may be 

5 hierarcWcallyoigan^ one event type may be a timer event. The timer 

may be further classified into catastrophic timer events, warning timer events, and 

infuiinatiuiial timer events, which are sub-eveiits. An informatio nal timer ev^nt may^ farther 

CLS be classified into start-up timer events and sh ut-down timer events. A liste nej^nav-regtster 

to listen for events at jyiy4evettrr3ieevent hierarchy. For example, a listener may register to 

D 10 <liSt5iToiJiifbjmatto ttal limei events. Thai listener would rcce iyfcanevent notification as for 

■ ■ ^ 

start-up timer events and ashut^dom u timer - e vents: A listener— will receiv e event 
for leaf events of the sub-tree correspond to the vent type registered. A leaf 
Tgnt that is not lu Tthu classified into - sub-tvenls. — An ev e nt typ e^nTSyTrave-4ts 



i-ri 




^> hierarchy embedde d in its name. For example th p "amp nf ctart-np tim^-^^^^^^y hp> 
□ 15 "fe mcr event/informational t ime e v ent/start up timer event. " 

is m ^8 ure ^3 * s a block diagram illustrating components of llie-evcnt 3ystcm in oqe 

f^mhrkdiment A clie nt 6301 re g^tfrS tr > bcten fnr-^venK hy wnilin^ <a listen mpToagP^nng 

^witluai L_event ty p e to the l istener component ^tO 2 - — Thtrclient ieceives"^frem^helistOT 
component an event notify message along with event information when an eventoftiiat-evdnt 
20 type is generated^JCli e - cli cnt un icgisteis its in terest in listening for events of a certain event 
e by sending a stop lis tming - messag e along with thc - event t y pe to t he l isteflexLQQm pone nt. 
In one ejnbodiment 7 -^fteh--imite^ as a listener component through which is routed all event- 
related mecc^ec far all listme™ <™ tha U iodo. The listene r comp eflentjnay in turnjqute 



^fvent-rplated triPQe^g^4rr^TT^fpnpr bus manager 6305. The listener component notifies the 
25 Mi s tmrr bu g manager tn lint e n for ^ 11 fiyf nt typfrfi for which listeners on that node hn yf 
registered. — The listener comp o n ent may S f H(l O n ly thf * ^^nrr bin mnmpr r- — OlltJ Hi>lWl 
gaessage for each- event type regardless of how many listcncwal tha t n ode have legisterethfe^ 
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that event type. For example, if a listener component tecdve s requests trom sixrHeflter-tke 
£y .list ener component s ends - only one listen me s sage to the list e n e r bus mana g ci : The listene r 
^component m flin tfnns a listener tnhln nnnhn 6106 thnt cnntainR a mapping frnm onoh - 
type for which a listen request has beenregiste^ed-aitd each client that has registered for that 
event type, ^h^rthelistener component receives an event notification, it uses the listener 

ener mat has registered tor tnat xvcnt type. — I n this way^he 
listener component reduces the event messages that are sentj3etwe£ii-thaH^ 
of the listener bus_managerr^When the listener component receives event notifications, it 
qnfws an evrnt n^tifirati^r fr r i^t™™^ — The lis t ener c o mponent ^ u ses- a s epara te 

0 10 thread for providing the event notification to each listener. If a single thread were^us&a^to 

ty 

y notify fnrh listenfiy^hf^eveni nohlinilions rnuld be delayed to some listeners as a result of a 

pj — drliy nr prnhl g m in notifying mm t l i i i lnj i wrm Tl t t^inn nf q cppqr^tp thrpfld ffl t each listener 

jjj ensures that the notification to one listener will not be delayed as a result_of_ 
mj "-""^"-tien-to another listener: The listener component may receive a bus state change 
sage. — it the bus goes do wn apd then comes hack up 3 the listener rnmp n nen t-Hsmr-re^ 



lU notificatien-1 
0 15 inessae^ — If 



i : : 



register with the listener bus manager to receive the e vents of the event types jm -its-ttstener 
table^aeh^r--^I : heiistener c<5mponent may also optimize its sending of listen requests based 
- the event hi e rarchy. For example^ if a listener registers to listen for a informa tional riiflety 
l onent will register that reg^st witn thp iist^n^r bus imflnr)C^ r T^aTT^fli^r 
listener registers to listen for a start-up timer, then the listener component will not need to 
registeTthatrequest with-the listener b us jnanager. Si nr p tfaU iQfr»nw rnmprmpt^-fT ^Q n 1r n nd y 
registered to receive a higher-level even t typp > it \<? ^irp^Hy rp^irtprpd tn rpn^wp -gtHhYw^ 
level 



The listener bus manager maintains a listener table 6307. The listener table 
25 contains a mapping from each event type to the registering nodes. When the listener bus 
manager receives an event posting, it notifies each node who has registered to listen for 
events of that event type and any event type that is a parent event type. The listener bus 
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manager queues event notifications in a manner that is similar to the queuing performed by 
the listener component. In particular, the listener bus manager allocates a different thread for 
each node to which an event notification is sent so that the event notifications to other nodes 
are not delayed because of problems in notifying one node. The listener bus manager may 
receive a node is down message and remove the entries from the listener table for that node 
so that no more event notifications will be sent to that node. A server 6302 may generate and 
post events by sending a post event message to the listener bus manager. The post event 
message includes event information that describes the event. The event information may 
include the event type, a time associated with the event, an indication of who generated the 
event, and the reason the event was generated. 

6. Logging System 

All log records are classified using an ASN. 1 Object Id. 
Standard Log record ASN.l Type Classification: 

1.x - All log records 

l.x.O - NonCritical 

l.x.0.0 - Trace output 

l.x.O. 1 - Progress 

1.x. 1 - Error 

l.x.2 - Warning 

Log records are composed of four fields of information: type, time, creator, 
information. Type and time are ASN.l ids while the creator can be either an ASN.l 
HcsResource instance id or a text string. The information field is the actual text generated 
by the logging component. 

^ The are v a rious components in the system that are responsible for th e 
collecting J stor a ge and po ssi ble forwnr rlin fi nFlo^ i mmls All fin i m of thin component are 
mnHplfid hy the HcsT ,ngFflr.i1ity rla^. 



/ 
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HcsLogFacility class 



T he HcsLogFacility cla s s is an HcsRcsouroe derivations who's purpose is to 
ade storage and forwarding at vari o us levels in the sys te m. — Theitr aie cuiitfiitfy^tw©- 
4mp le.mpntflfinTi<;- thp.J.nr.a1 T Fa ci lity, a n d tV rrm trn1 T n g Fnrihty Thf> Hr^T r'gFnrili ty 



5 interface is: - 



class HcsLogFacility : public HcsResource 
public: 



10 



o 

PU 



15 




virtual HRESULT putRecord ( char* typeAsnlldStrPtr, 

char* timeAsnlStrPtr, 
char* idStrPtr, 
char* recordPtr ) = 0; 



The Local Log Facility 



^ Vln TVifinl Log Fnmlity (T . T F) ingf^nrp (only rmel) pyi<^ -w-f»T7PT^ tinTtt^w-^hp 

system. The purpose of this HcsLo|£a^ accept all log records from 

various HCS^cCniponents on that node and to buffer them in a large circular on disk until 
£y can b e delivered tn th e Central Tog F acil ity ( r f F - ) — The intent is that anodo^cg jtild 
survive for some time if theCIJLj^^ One of the configuration 
parameters 



yernHTavailable. 

25 parameters nassetTto each Local HcsLogFacility instance will be the resource name of the 

^Facility thro ugh whinh th^ l i i mlMiU 'n k U\ fin w,htH itr rernrA^ Thp current thi^^C is 

that this 



re name of the CLF but this is not an architectural requirement, in oftier 
w oi ds thcie Ci) Uld be intermediate levels of HcsLogFatililies placed in the system, In fact ion 

— ; 

LLF rould be configufe^irrforwm^ its records to another LLF. After all a HcsLogFacility is 
30 -^a HcsLogFacility : — * 



[30581-8002/Application.doc] 




56 

The Central Log Facility 

There will be one instance of the Central Log Fac/lity (CLF) instance in the 
entire system. The purpose of this HcsLogFacility implementation is to accept all log 
records from various HCS components within the entire system and to provide for the final 
storage of this information. The intent is that this facility provide for the long term, off line, 
archival of the entire HCS system log. In addition to this function, it will also provide for the 
on-line viewing of some portion of the log. 

How log records are written 

. So-the question is: how do HCS components log th e re information ? — To 
flcT pr^vH'* a stflr"ia r d fl n d sa ff > a^pcc tn tVi^ UrcT ngF^jh ties , t her e is a class family provide d? 




The family is baaed at a cl ass called H c sLogPort. — This clas s implements the commo n 
behavior nf nil typr^ nPT i ^P 1 ' "^ nnH h fhnr tion n l r*n its own 

BeriWd — fmn — the — HcsLogPort — "are — Efte — HcsResu m cuLugPui t — and- 
HcsLogFacil itv Pnrt clnfiflffl Thr H^nFvsmm vT J^Pn l pn^nrip rnny support for th^ rf -s f nrrr^ 
3 15 devel oper while the HcsLogFacilitvPort provides dires t-ac cess to HcsL o MFaLil i t ies. *ln 
geirmd , the first is us^d by Rrsourrr derivations wh il e the soc^d w^ 4d be u sed by resour ce 
ser vers and system components. * 




20 { 



class HcsLogPort 
public: 

/* Global Constant AsnObjectlds for all defined log record types — 
SEE INCLUDE FOR TYPE LIST */ 
#include <HcsLogRecTypes.h> 



25 



public: 

HcsLogPort ( char* idStrPtr ) ; 
virtual -HcsLogPort ( void ); 

void put ( const AsnlObjectld* typePtr, char* formatStrPtr, ... ) ; 
30 inline char* getldStrPtr ( void ) { return( myldStrPtr ); }; 

l 
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BOOL setldStr ( char* newIdStrPtr ); 

/* Methods to control log filtering */ 
void enable ( char* asnlldOfLogRecTypeToEnablePtr ); 
void disable ( char* asnlldOfLogRecTypeToDisablePtr ); 
BOOL isEnabled ( char* asnlldOfLogRecTypeToChkPtr ); 
BOOL isEnabled ( const AsnlObjectld* logRecTypeToChkPtr ); 
inline HRESULT dumpFiiterState ( TextSink* toSinkPtr, int 
maxLineSize ) 

{ return( myFilter.dumpState( toSinkPtr ) ); }; 
inline void resetFilter ( void ) { myFilter.resetQ; }; 



void forwardRec ( const AsnlObjectld* typePtr, char* timeAsnlStrPtr, 
char* idStrPtr, char* recordPtr ) ; 

/* used to forward from one 
HcsLogPort implementation to another */ 

protected: 

/* Derivation Interface */ 

/* Defaults to writing errors only to the NT SystemLog */ 
virtual void dumpRec( const AsnlObjectld* typePtr, char* 
timeAsnlStrPtr, char* idStrPtr, char* recordPtr ) ; 

private: 

void putOver ( void ) ; 

HcsLogPort ( void ) ; 

void* operator new ( sizet size ) ; 

private: 

char* myldStrPtr; 
HANDLE myHandle; 
DWORD myldEvent; 
AsnlSet myFilter; 

public: 

/* Grand fathered Methods */ 
void setTrace ( BOOL to ); 
void setProgress ( BOOL to ); 
void setWarning ( BOOL to ); 
BOOL isTraceEnabled ( void ); 
BOOL isProgressEnabled ( void ); 
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BOOL isWarningEnabled ( void ); 
void putError ( char* formats trPtr, ... ) ; 
void putWarning ( char* formats trPtr, ... ) ; 
void putTrace ( char* formats trPtr, ... ) ; 
void putProgress ( char* formatStrPtr, ... ) ; 
void putMaintFailure ( char* formatStrPtr, ... ) ; 



/* class used by resource implementors */ 
class HcsResourceLogPort : public HcsLogPort 

public: 

HcsResourceLogPort ( HcsResourcelmp* ownerPtr, char* idStrPtr ); 
virtual -HcsResourceLogPort ( void ); 

protected: 

/* routes all output through the owning HcsResourcelmp's 
putLogRecord private support method */ 

void dumpRec( char* typeAsnl IdStrPtr, char* timeAsnlStrPtr, char* 
idStrPtr, char* recordPtr ); 



private: 

HcsResourceLogPort ( void ); 
void* operator new ( sizet size ); 

}; 



/* class used by non resource centric implementations */ 
class HcsLogFacilityPort : public HcsLogPort 

public: 

HcsLogFacilityPort ( char* idStrPtr ); 

HcsLogFacilityPort ( HcsLogFacility* facilityPtr, char* idStrPtr ); 

HRESULT setFacility ( HcsLogFacility* facilityPtr ); 

HRESULT clearFacility ( void ); 

BOOL isFacilitySet ( void ); 
inline BOOL isTapped ( void ) { return( mylsTapped ); }; 
inline void setTapOn ( void ) { mylsTapped = TRUE; } ; 
inline void setTapOff ( void ) { mylsTapped = FALSE; }; 



virtual -HcsLogFacilityPort ( void ); 
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protected: 

/* defaults to writing errors only to the NT SystemLog (chicago??) 
unless an HcsLogFacility is made available 
and is functioning */ 

void dumpRec ( const AsnlObjectld* typePtr, char* timeAsnlStrPtr, 
char* idStrPtr, char* recordPtr ) ; 

private: 

HcsLogFacilityPort ( void ) ; 

void* operator new ( size t size ) ; 
private: 

HcsLogFacilityOlePtr myFacOlePtr; 
BOOL mylsFacSet; 
BOOL raylsTapped; 




Effects on the HcsResourcelmp Interface 
^ j jIcsRcsoui ' ccImp : :putLogR.ocord — implementation k eep s and — -internal 

RpgT ngF^ilityPnrt inotan^g ^ ig h i g 1irnH tr t forw a rd fYv rrrr j l l! l lwM.m h Up rni^rprnr ^ cf 

ac tually fory^ ^ HcsResource lm p checks to make sure an Hr.sT ngF n mlity hnr . hnnn nnntgn 
to its port. If thi s is not the case, an attempt is made t o locate the local HcsLogFacility for 
that nod e via the HcsR e srcBusIf::locateLocalResourceById m e thod (n e w). In any case, thcT 
-hT^rmn-d is written t ft thfr ina the resoH m HnslH i Hr ' s HrsI i ^Fnril il y-R f^Ft, 



New: The HcsResource interface defines, and the HcsResourcelmp 
25 implements, two methods: 



HRESULT enableLogging ( [in, string]char* forLogRecClassPtr ); 
HRESULT disableLogging ( [in, string]char* forLogRecClassPtr ); 

These are used by support to enable and disable logging dynamically within 
instances of HcsResources. 
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The HcsLogFacility class and HcsLogFacilityPorts 

Notice that any HcsLogFacility can be referenced by a HcsLogFacilityPort. 
This means that some components may wish to connect directly to the CLF. A good 
example of this may be the Resource Bus Manager (RBMGR.EXE). 

Although specific embodiments of, and examples for, the present invention are 
described herein for illustrative purposes, it is not intended that the invention be limited to 
these embodiments. Equivalent methods, structures, processes, steps and other modifications 
within the spirit of the invention fall within the scope of the invention. Accordingly, the 
invention is not limited to the specific embodiments, but instead the scope of an invention is 
specified by the following claims. 
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